From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:55 2006 Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0001.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0001.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:18 2006 Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0002.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0002.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor@opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:15 2006 Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj@www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0003.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0003.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0004.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0004.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0005.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0005.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0006.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0006.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0007.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0007.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0008.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0008.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0009.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0009.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0010.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0010.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0011.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0011.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0012.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0012.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0013.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0013.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0014.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0014.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0015.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0015.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0016.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0016.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0017.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0017.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0018.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0018.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0019.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0019.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0020.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0020.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0021.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0021.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0022.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0022.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0023.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0023.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0024.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0024.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0025.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0025.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0026.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0026.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0027.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0027.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0028.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0028.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0029.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0029.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0030.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0030.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0031.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0031.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0032.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0032.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0033.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0033.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0034.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0034.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0035.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0035.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0036.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0036.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0037.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0037.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0038.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0038.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0039.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0039.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0040.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0040.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0041.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0041.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0042.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0042.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0043.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0043.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0044.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0044.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0045.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0045.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0046.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0046.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0047.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0047.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0048.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0048.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0049.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0049.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0050.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0050.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0051.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0051.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0052.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0052.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0053.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0053.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0054.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0054.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0055.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0055.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0056.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0056.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0057.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0057.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0058.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0058.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0059.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0059.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0060.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0060.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0061.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0061.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0062.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0062.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0063.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0063.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0064.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0064.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0065.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0065.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0066.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0066.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0067.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0067.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0068.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0068.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0069.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0069.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0070.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0070.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0071.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0071.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0072.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0072.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0073.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0073.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0074.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0074.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0075.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0075.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0076.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0076.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0077.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0077.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0078.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0078.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0079.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0079.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0080.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0080.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0081.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0081.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0082.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0082.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0083.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0083.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0084.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0084.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0085.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0085.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0086.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0086.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0087.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0087.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0088.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0088.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0089.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0089.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0090.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0090.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0091.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0091.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0092.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0092.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0093.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0093.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0094.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0094.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0095.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0095.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0096.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0096.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0097.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0097.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0098.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0098.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0099.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0099.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0100.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0100.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0101.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0101.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0102.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0102.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0103.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0103.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0104.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0104.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0105.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0105.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0106.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0106.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0107.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0107.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0108.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0108.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0109.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0109.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0110.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0110.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0111.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0111.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0112.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0112.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0113.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0113.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0114.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0114.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0115.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0115.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0116.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0116.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0117.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0117.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0118.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0118.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0119.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0119.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0120.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0120.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0121.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0121.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0122.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0122.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0123.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0123.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0124.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0124.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0125.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0125.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0126.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0126.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0127.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0127.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0128.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0128.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0129.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0129.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0130.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0130.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0131.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0131.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0132.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0132.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0133.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0133.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0134.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0134.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0135.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0135.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0136.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0136.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0137.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0137.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0138.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0138.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0139.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0139.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0140.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0140.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0141.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0141.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0142.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0142.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0143.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0143.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0144.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0144.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0145.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0145.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0146.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0146.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0147.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0147.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0148.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0148.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0149.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0149.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0150.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0150.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0151.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0151.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0152.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0152.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0153.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0153.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0154.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0154.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0155.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0155.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0156.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0156.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0157.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0157.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0158.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0158.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0159.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0159.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0160.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0160.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0161.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0161.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0162.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0162.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0163.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0163.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0164.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0164.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0165.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0165.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0166.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0166.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0167.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0167.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0168.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0168.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0169.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0169.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0170.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0170.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0171.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0171.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0172.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0172.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0173.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0173.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0174.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0174.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0175.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0175.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0176.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0176.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0177.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0177.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0178.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0178.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0179.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0179.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0180.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0180.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0181.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0181.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0182.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0182.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0183.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0183.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0184.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0184.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0185.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0185.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0186.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0186.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0187.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0187.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0188.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0188.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0189.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0189.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0190.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0190.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0191.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0191.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0192.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0192.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0193.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0193.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0194.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0194.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0195.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0195.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0196.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0196.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0197.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0197.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0198.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0198.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0199.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0199.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0200.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0200.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0201.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0201.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0202.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0202.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0203.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0203.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0204.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0204.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0205.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0205.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0206.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0206.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0207.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0207.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0208.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0208.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0209.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0209.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0210.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0210.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0211.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0211.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0212.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0212.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0213.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0213.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0214.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0214.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0215.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0215.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0216.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0216.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0217.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0217.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0218.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0218.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0219.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0219.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0220.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0220.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0221.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0221.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0222.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0222.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0223.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0223.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0224.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0224.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0225.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0225.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0226.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0226.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0227.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0227.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0228.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0228.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0229.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0229.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0230.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0230.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0231.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0231.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0232.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0232.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0233.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0233.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Trent Go to the bottom of it. Since the application is to work on Win and Lin the required port is identified by number alone, so port 1 on win is Com1, on Linux it is /dev/ttyS1. When acquiring the port, I test the port type as being serial and the match the end of the port name with the required port number. Ok so far. The target platform had a usb serial interface plugged in, this is identified as /dev/ttyUSB0, and of type serial. This port was being identified and used and not the ttyS0. It worked fine as far as the output went, but it looks as though the event signalling from the USB serial is not working. I removed the usb serial and /dev/ttyS0 was correctly assigned and the event signalling works. I tried the usb serial on windows, with the Sun comm. Api. The port was identified as COM4 and worked like a charm. Next step get the RXTX interface working in Windows, at the moment I am switching the import between gnu.io and javax.comm Perhaps once the dust has settled on this project, (the normal mad rush to get something working), I could have a look at the nuts and bolts of the USB interface on linux. Unless of course someone has already done so :-) Thanks for all the help. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From george.palmer at gmail.com Fri Dec 10 16:39:37 2004 From: george.palmer at gmail.com (George Palmer) Date: Fri, 10 Dec 2004 23:39:37 +0000 Subject: [Rxtx] RXTX performance Message-ID: The last post about the SerialPortListener made me think about serial port performance. A few tests later and it appears the Java Sun Comm version takes around 10ms per query for my external device, whereas using RXTX native takes around 15ms. I've since narrowed this down to the time the EventListener takes to fire. Looking at the outline code from the last post I guess there's some way of altering the check frequency within the native file, but I'm really getting in over my head here. Can anybody advise me? By the way I do lots of queries so 5ms is really a 50% increase, not some negligible amount of time. Thanks in advance for any pointers, George From taj at www.linux.org.uk Sat Dec 11 00:49:13 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 11 Dec 2004 07:49:13 +0000 (GMT) Subject: [Rxtx] RXTX performance In-Reply-To: References: Message-ID: On Fri, 10 Dec 2004, George Palmer wrote: > The last post about the SerialPortListener made me think about serial > port performance. A few tests later and it appears the Java Sun Comm > version takes around 10ms per query for my external device, whereas > using RXTX native takes around 15ms. I've since narrowed this down to > the time the EventListener takes to fire. > > Looking at the outline code from the last post I guess there's some > way of altering the check frequency within the native file, but I'm > really getting in over my head here. Can anybody advise me? > > By the way I do lots of queries so 5ms is really a 50% increase, not > some negligible amount of time. > > Thanks in advance for any pointers, > Hi George The fastest I've ever gotten rxtx while watching with an untuned oscilloscope (I got it for $5 in a pallet of 'junk') was just under 10 ms. Odd enough the setup was Linux and windows 98 in vmware on Linux. Linux was just under 10 ms and windows in vmware was ~8 ms. I've read that XP/2K are now also less responsive to serial ports. This would make sense as kernels are more interested in schedualing and memory managment unrelated to sub 10 ms serial port responses. Really all you need to do is go through the rxtx code and search for sleep, usleep,nanosleep, Thread.sleep(). The only catch is that when data is available, the select() will not block causing very high CPU use if you dont sleep some. poll() could be used but is not. Native code racing in rxtx is a disaster to JRE behavior. Swing and other GUI components are the first to start showing the bad side. Just a warning. The 15 ms is somewhat deliberate here but you could get it down to 10ms or even perhaps < 5 ms with kernel changes. But the people that want that should understand that the kernel does not garantee such behavior. Java and kernels are abstraction layers on the hardware. Odd enough one of the first things to start showing problems in Linux when they started advanced schedualing was the mouse movement didnt feel responsive. A paper even covered this at last years symposium. When people start seeing sub 10MS response times, they start thinking about doing RS485 in software. RS485 does some bits on the control lines in hardware that are time sensitive. Then people think they can do RS485 with set()/get() over two layers of hardware abstraction using a RS232 port saving them $5 in hardware and some reading. Well, You can probably get sub 10 MS but I'd rather see people live with 15MS and not go into 10 MS questions that will pop up :) You do have a fair amount of control of the Linux kernel. Look for real time linux or rtlinux. But you will still have to deal with whatever the JRE does for schedualing. In theory a native program should be doing this in the usec range with a realtime kernel. If you can, just let rxtx sleep. Let the JRE do its thing. You wont find odd things showing up now and then. But if you need to, you can probably shave off 5 ms just by finding the right sleep. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 13:15:00 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 20:15:00 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open Message-ID: <000001c4dbd0$47097860$2b001eac@aries> Greetings all I am new to the list but would like to thank you all for your past posts, most helpful. However I have come to a halt. I am writing an application on a Suse Linux platform. To get it woking I download the latest code from the CVS repository today. The application starts up correctly and identifies all of the port on the target. However, once I have selected the serial port I wish to use I execute the method shown below to open the port and get the SerialPort object, from the CommPortIdentifier. As soon as the portId.open is exceuted I get the exception; 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. /** * get a SerialPort object associated with a port object * @param portId * @return */ private SerialPort getSerialPortObject(CommPortIdentifier portId) { SerialPort sp = null; try { sp = (SerialPort)portId.open(getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return sp; } 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th November 2004 port /dev/ttyS0 found FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) Experimental: JNI_OnLoad called. I tried a variation to just return the CommPort object, with the method below, but this behaves the same with the same exception. /** * get a SerialPort object associated with a port object * @param portId * @return */ private CommPort getCommPortObject(CommPortIdentifier portId) { CommPort commPort = null; try { commPort = portId.open( getClass().getName() + portId.getName(), mPortConnectionTimeOut); } catch (Exception ex) { Logger.getInstanceOf().outExceptionStackTrace("" , ex); } return commPort; } Any help or comments most welcome. I am using the native RXTXcomm.jar and the gnu.io.drivers, createad in the build from the source code I down loaded today. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041206/a28c7117/attachment-0234.html From taj at www.linux.org.uk Mon Dec 6 13:39:01 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 6 Dec 2004 20:39:01 +0000 (GMT) Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: <000001c4dbd0$47097860$2b001eac@aries> References: <000001c4dbd0$47097860$2b001eac@aries> Message-ID: On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Mon Dec 6 16:27:41 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 6 Dec 2004 23:27:41 -0000 Subject: [Rxtx] Problem with CommPortIdentifier.open In-Reply-To: Message-ID: <000c01c4dbeb$31d72f80$2b001eac@aries> Trent Well spotted. When I first started on this at the end of last week I was getting the VM abort problem. I had been trying a lot of things to sort that problem, before I down loaded the latest source this morning. After building that the vm abort problem had gone. However, I had left -Xcheck on. I have removed that, and the CommPortIdentifier.open behaves properly. Incidentally, this is java 1.4.2_03. The reason for this is the cross platform development IDE, Oracle JDeveloper 10g. This has only been validated to this version of Java. Thank you for your prompt response and all your efforts in this project. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 06 December 2004 20:39 To: Java RXTX discussion Subject: Re: [Rxtx] Problem with CommPortIdentifier.open On Mon, 6 Dec 2004, Trevor Sutton wrote: > Greetings all > > I am new to the list but would like to thank you all for your past > posts, most helpful. > > However I have come to a halt. > > I am writing an application on a Suse Linux platform. To get it woking I > download the latest code from the CVS repository today. The application > starts up correctly and identifies all of the port on the target. > However, once I have selected the serial port I wish to use I execute > the method shown below to open the port and get the SerialPort object, > from the CommPortIdentifier. As soon as the portId.open is exceuted I > get the exception; > > 06.12.2004 at 19:24:14 >>> Hermes IO RS232. Version 0.1 24th > November 2004 > port /dev/ttyS0 found > FATAL ERROR in native method: Field type (instance) mismatch in JNI > get/set field operations > at gnu.io.RXTXPort.eventLoop(Native Method) > at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) > Experimental: JNI_OnLoad called. Hi Trevor, I'm curious which virtual machine, version and command line arugments are being passed. It appears there may be problems with the JNI checks that 1.4 JRE's perform: http://tinyurl.com/5vafh >> Gordon Beaton Mar 14 2002, 7:57 am show options Newsgroups: comp.lang.java.programmer From: Gordon Beaton Date: 14 Mar 2002 15:57:01 GMT Local: Thurs, Mar 14 2002 7:57 am Subject: Re: problem with jdk 1.4 and java -Xcheck:jni On 13 Mar 2002 10:25:25 -0800, K. Juenemann wrote: > whenever I use the JNI function 'GetStaticObjectField' and run the > program with 'java -Xcheck:jni' under jdk 1.4 I get the error > message > FATAL ERROR in native method: Field type (static) mismatch in JNI > get/set field operations > Under jdk 1.3 everything works fine. Has anybody seen something > similar ? Your code looks ok to me. It also works exactly as expected if you don't ask the JVM to make these checks. Interestingly enough, if you make "x" non-static and make the appropriate changes to the native code, the error goes away. The JDC bug database has a handfull of bugs involving Xcheck:jni on 1.4, none of them exactly this but similar. The source for JDK 1.4 isn't yet available, so it's hard to look further into this at the moment. /gordon << -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 04:02:49 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:02:49 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener Message-ID: <000b01c4dc4c$4dcd9380$2b001eac@aries> I have nearly managed to port my java comms application form Windows to Linux, thanks to the information in this list. Hopefully onto the last problem. The SerialPortEventListener does not seem to be listening. It works fine on Windows with the Sun comm. Api, but not on Linux, although the Serial Port listener has been added to the Serial port object without any exception or apparent errors. Data is being transmitted from the port and I currently have an external loopback. Is anybody aware of any problems or tricks with the RXTXcomm implementation for SerialPortEventListener. I have had a good look through the archives, but to no avail, and looking at the code downloaded from CVS yesterday looks much the same. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20041207/609fc4ff/attachment-0234.html From taj at www.linux.org.uk Tue Dec 7 04:27:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 7 Dec 2004 11:27:35 +0000 (GMT) Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: <000b01c4dc4c$4dcd9380$2b001eac@aries> References: <000b01c4dc4c$4dcd9380$2b001eac@aries> Message-ID: On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk From trevor at opecsystem.com Tue Dec 7 04:35:50 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 11:35:50 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <001901c4dc50$eab80780$2b001eac@aries> Morning Trent The only events I am looking for while trying to get the port up and running are the Data_available and the output_buffer_empty. The test target at the moment is a standard PC running Suse v9.0 I was just building some of the code from the CVS, to try and eliminate my typing errors, (although I am sure there aren't any :-) ) Failing that I will have a look into the event loop. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Trent Jarvi Sent: 07 December 2004 11:28 To: Java RXTX discussion Subject: Re: [Rxtx] Linux and the SerialPortEventListener On Tue, 7 Dec 2004, Trevor Sutton wrote: > I have nearly managed to port my java comms application form Windows to > Linux, thanks to the information in this list. > > Hopefully onto the last problem. The SerialPortEventListener does not > seem to be listening. It works fine on Windows with the Sun comm. Api, > but not on Linux, although the Serial Port listener has been added to > the Serial port object without any exception or apparent errors. > > Data is being transmitted from the port and I currently have an external > loopback. Is anybody aware of any problems or tricks with the RXTXcomm > implementation for SerialPortEventListener. > > I have had a good look through the archives, but to no avail, and > looking at the code downloaded from CVS yesterday looks much the same. > > Hi Trevor, Some ports are not capable of all events so I'm curious which events you are looking for and what type of serial port you have. Some ports dont have Ring Indicator. Others need to have data flushed after writing to know when OUTPUT_BUFFER_EMPTY should be sent. Normal PC ports can usually do everything. rxtx-devel/contrib/SimpleRead.java has a program you can hack into a simple test of events. Using printf("here\n"); in SerialImp.c you should be able to figure out if the eventLoop and subsequent functions are behaving. I'm not aware of a problem with too few events. A simplified eventLoop follows. You can see if you follow the logic, you should see that the port is waiting for changes and then reporting them. /*---------------------------------------------------------- RXTXPort.eventLoop accept: none perform: periodically check for SerialPortEvents return: none exceptions: none comments: please keep this function clean. ----------------------------------------------------------*/ JNIEXPORT void JNICALL RXTXPort(eventLoop)( JNIEnv *env, jobject jobj ) { ... do { // wait for the port to change eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); printf("TICK\n"); // report events. if(eis.eventflags[SPE_DATA_AVAILABLE] ) ..send data available report_serial_events( &eis ); } while ( !closing ) ... } The above psuedocode should at least print out TICK, TICK, TICK... as the select times out or is interrupted by events. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From trevor at opecsystem.com Tue Dec 7 12:20:01 2004 From: trevor at opecsystem.com (Trevor Sutton) Date: Tue, 7 Dec 2004 19:20:01 -0000 Subject: [Rxtx] Linux and the SerialPortEventListener In-Reply-To: Message-ID: <000001c4dc91$c308f7d0$2b001eac@aries> Tre